Web services have become a significant aspect of modern networking. Web services have widespread utility in conducting modern network based commercial transactions and other business functions, which have proliferated with rapid, recent development in fields relating to computing, networking, communications and others. In such fields, web services allow two remote applications that are networked with the network to communicate with each other and exchange information.
The requestor/response model and the one way message model represent typical modern web service paradigms. The requestor/response model functions with a mechanism wherein a requester sends out a request message and gets back a response message from a responder. The one way model functions with a mechanism wherein a sender sends out a message with no provision required for awaiting a response.
In the familiar requestor/response model, a requester sends a request message to the service provider, and then receives its response message. These web services functions are performed using Simple Object Access Protocol (SOAP), and Web Service Definition Language (WSDL). SOAP represents how the requester above communicates with the service provider.
UDDI allows a global lookup base for locating services and represents the index service of the exemplary server above. Thus the requestor accesses information relating to the service being sought. The services are described in the UDDI with WSDL, which maps to the information in the server. Web services transaction and other information may comprise data in Extensible Markup Language (XML).
A more recently emerging (e.g., currently still maturing) rather sophisticated web services model uses techniques sometimes referred to as “orchestration” and/or “choreography” to effectuate a complex message exchange process. For instance, a central coordinator is typical in such schemes to send and receive messages. The central coordinator functions to determine a path and route the message through the network to an appropriate endpoint (e.g., destination) according to certain pre-defined flow logic with which it is programmed.
Messages sent according to this model route through the central coordinator as a single point of control, which determines for example when the message should be routed to a next step, routed along a subsequent hop, etc. For applications requiring fast real-time response, this single point of control however has the potential to become a bottleneck for its message traffic. Bottlenecking at the central coordinator in this model can have significant impact on web services related parameters such as overall throughput and response time.
In contrast to the central coordinator based model, one conventional approach uses a web services intermediary. The web services intermediary tries to intercept messages along their transport path, perform some processing thereon and forward the message on towards its final (e.g., designated) destination. This architecture is typically used for effective insertion of message processing logic along the message path.
This processing logic however typically relates to control in the intermediary itself (e.g., proxies, gateways), which are very localized and optimized for the networked entity to which they belong and may thus lack a more global view, e.g., of other intermediaries involved in a request/response, etc. Moreover, the lack of a central coordinator or similar central control point can complicate tracing a message's routing path and/or debugging the corresponding message processing logic.
Thus, the available conventional web services approaches can demand a tradeoff between manageability and efficiency. Conventional web services and XML environments thus do not function (e.g., lack adequate mechanisms) to simultaneously handle a message stream with both high efficiency, e.g., without potential bottlenecking in a single control point, and the high manageability available with centralized flow control.
For instance, the centralized control characteristic of the conventional orchestration approach promotes manageability, but can devolve in some circumstances into a traffic bottleneck that impacts efficiency. The conventional intermediary approach, on the other hand, allows each gatekeeper (e.g., gateway, proxy) to make trafficking decisions locally. However, there may be issues that can complicate tracking, e.g., why a certain traffic decision is made, which can impact manageability.
Moreover, the architectures characterizing these conventional web services are not designed to optimize stream processing of messages wherein message processing need to happen before the full message is received. “Stream processing capability” is very important for providing high throughput of large messages or continuous data.
The conventional web services architecture may thus not optimally support streaming. In the traditional request/response model, a service provider is essentially constrained to responding to the original service requester, resulting in a lot of roundtrips when multiple service providers are involved. Conventional web services are essentially stateless, because services are constrained from specifying the sequence of messages it expects. Stream processing is a challenge to conventional web services, because a service therein is constrained to getting a message essentially in its entirety before beginning processing related thereto.